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Requirements for robust IP/UDP/RTP header compression 
Status of this Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 
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Abstract 


This document contains requirements for robust IP/UDP/RTP (Internet 
Protocol/User Datagram Protocol/Real-Time Transport Protocol) header 
compression to be developed by the ROHC (Robust Header Compression) 
WG. It is based on the ROHC charter, discussions in the WG, the 3GPP 
document "3GPP TR 23.922", version 1.0.0 of October 1999, as well as 
contributions from 3G.IP. 


1. Introduction 


The goal of the ROHC WG is to develop header compression schemes that 
perform well over links with high error rates and long link round 
trip times. The schemes must perform well for cellular links built 
using technologies such as WCDMA, EDGE, and CDMA-2000. However, the 
schemes should also be applicable to other future link technologies 
with high loss and long round trip times. 


The following requirements have, more or less arbitrarily, been 
divided into three groups. The first group deals with requirements 
concerning the impact of an header compression scheme on the rest of 
the Internet infrastructure. The second group concerns what kind of 
headers that must be compressed efficiently. The final group 
concerns efficiency requirements and requirements which stem from the 
properties of the anticipated link technologies. 


2. Header compression requirements 
Several current standardization efforts in the cellular arena aim at 


supporting voice over IP and other real-time services over IP, e.g., 
GERAN (specified by the ETSI SMG2 standards group), and UTRAN 
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(specified by the 3GPP standards organization). It is critical for 
these standardization efforts that a suitable header compression 
scheme is developed before completion of the Release 2000 standards. 
Therefore, it is imperative that the ROHC WG keeps its schedule. 


2.1 Impact on Internet infrastructure 


1. Transparency: When a header is compressed and then decompressed, 
the resulting header must be semantically identical to the original 
header. If this cannot be achieved, the packet containing the 
erroneous header must be discarded. 


Justification: The header compression process must not produce 
headers that might cause problems for any current or future part of 
the Internet infrastructure. 


2. Ubiquity: Must not require modifications to existing IP (v4 or 
v6), UDP, or RTP implementations. 


Justification: Ease of deployment. 
Note: The ROHC WG may recommend changes that would increase the 
compression efficiency for the RTP streams emitted by 
implementations. However, ROHC cannot rely on such recommendations 
being followed. 

2.2 Supported headers and kinds of RTP streams 
1. IPv4 and IPv6: Must support both IPv4 and IPv6. 


Justification: IPv4 and IPv6 will both be around during the 
foreseeable future. 


2. Mobile IP: The kinds of headers used by Mobile IP{v4,v6} should be 
compressed efficiently. For IPv4 these include headers of tunneled 


packets. For IPv6 these include headers containing the Routing 
Header, the Binding Update Destination Option, and the Home Address 
option. 


Justification: It is very likely that Mobile IP will be used by 
cellular devices. 


3. Genericity: Must support compression of headers of arbitrary RTP 
streams. 
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Justification: There must be a generic scheme which can compress 
reasonably well for any payload type and traffic pattern. This does 
not preclude optimizations for certain media types where the traffic 
pattern is known, e.g., for low-bandwidth voice and low-bandwidth 
video. 


Note: This applies to the RTP stream before as well as after it has 
passed through an internet. 


4. IPSEC: ROHC should be able to compress headers containing IPSEC 
subheaders. 


Note: It is of course not possible to compress the encrypted part of 
an ESP header, nor the cryptographic data in an AH header. 


2.3 Efficiency 


1. Performance/Spectral Efficiency: Must provide low relative 
overhead under expected operating conditions; compression efficiency 
should be better than for RFC 2508 under equivalent operating 
conditions. The error rate should only marginally increase the 
overhead under expected operating conditions. 


Justification: Spectrum efficiency is a primary goal. RFC 2508 does 
not perform well enough. 


Note: The relative overhead is the average header overhead relative 

to the payload. Any auxiliary (e.g., control or feedback) channels 

used by the scheme should be taken into account when calculating the 
header overhead. 


2. Error propagation: Error propagation due to header compression 
should be kept at an absolute minimum. Error propagation is defined 
as the loss or damage of headers subsequent to headers lost or 
damaged by the link, even if those subsequent headers are not lost or 
damaged. 


Justification: Error propagation reduces spectral efficiency and 
reduces quality. CRIP suffers severely from error propagation. 


Note: There are at least two kinds of error propagation; loss 
propagation, where an error causes subsequent headers to be lost, and 
damage propagation, where an error causes subsequent headers to be 
damaged. 
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3a. Handover loss events: There must be a way to run ROHC where loss 
events of length 150 milliseconds are handled efficiently and where 
loss or damage propagation is not introduced by ROHC during such 
events. 


Justification: Such loss events can be introduced by handover 
operations in a (radio) network between compressor and decompressor. 


Handover operations can be frequent in cellular systems. Failure to 
handle handover well can adversely impact spectrum efficiency and 
quality. 


3b. Handover context recreation: There must be a way to run ROHC that 
deals well with events where the route of an RTP conversation changes 
such that either the compressor or the decompressor of the 
conversation is relocated to another node, where the context needs to 
be recreated. ROHC must not introduce erroneous headers during such 
events, and should not introduce packet loss during such events. 


Justification: Such events can be frequent in cellular systems where 
the compressor/decompressor on the network side is close to the radio 
base stations. 


Note: In order to aid developers of context recreation schemes where 
context is transfered to the new node, the specification shall 
outline what parts of the context is to be transfered, as well as 
conditions for its use. Procedures for context recreation (and 
discard) without such context transfer will also be provided. 


4. Link delay: Must operate under all expected link delay conditions. 


5. Processing delay: The scheme must not contribute significantly to 
system delay budget. 


6. Multiple links: The scheme must perform well when there are two or 
more cellular links in the end-to-end path. 


Justification: Such paths will occur. 


Note: loss on previous links will cause irregularities in the RTP 
stream reaching the compressor. Such irregularities should only 
marginally affect performance. 


Ja. Packet Misordering: The scheme should be able to compress when 
there are misordered packets in the RTP stream reaching the 
compressor. No misordering is expected on the link between 
compressor and decompressor. 
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Justification: Misordering happens regularly in the Internet. 
However, since the Internet is engineered to run TCP reasonably well, 
excessive misordering will not be common and need not be handled with 
optimum efficiently. 


7b. Moderate Packet Misordering: The scheme should efficiently handle 
moderate misordering (2-3 packets) in the packet stream reaching the 
compressor. 


Note: This kind of reordering is common. 


8. Unidirectional links/multicast: Must operate (possibly with less 
efficiency) over links where there is no feedback channel or where 
there are several receivers. 


9. Configurable frame size fluctuation: It should be possible to 
restrict the number of different frame sizes used by the scheme. 


Justification: Some radio technologies support only a limited number 
of frame sizes efficiently. 


Note: Somewhat degraded performance is to be expected when such 
restrictions are applied. 


Note: This implies that a list of "good" frame sizes must be made 
available and that ROHC may pick a suitable header format to utilize 
available space as well as possible. 


10. Delay: ROHC should not noticeably add to the end-to-end delay. 


Justification: RTP packets carrying data for interactive voice or 
video have a limited end-to-end delay budget. 


Note: This requirement is intended to prevent schemes that achieve 
robustness at the expense of delay, for example schemes that require 
that header it+x, x>0, is received before header i can be 
decompressed. 


Note: Together with 2.3.5, this requirement implies that ROHC will 
not noticeably add to the jitter of the RTP stream, other than what 
is caused by variations in header size. 


Note: This requirement does not prevent a queue from forming upstream 
a bottleneck link. Nor does it prevent a compressor from utilizing 


information from more than one header in such a queue. 


11. Residual errors: For a residual bit-error rate of at most le-5, 
the ROHC scheme must not increase the error rate. 


Degermark Informational [Page 5] 


RFC 3096 Requirements for IP/UDP/RTP ROHC July 2001 


Justification: Some target links have a residual error rate, i.e, 
rate of undetected errors, of this magnitude. 


Note: In the presence of residual bit-errors, ROHC will need error 
detection mechanisms to prevent damage propagation. These mechanisms 
will catch some residual errors, but those not caught might cause 
damage propagation. This requirement states that the reduction of 
the damage rate due to the error detection mechanisms must not be 
less than the increase in error rate due to damage propagation. 


3. IANA Considerations 


A protocol which meets these requirements, e.g., [ROHC], will require 
the IANA to assign various numbers. This document by itself, 
however, does not require any IANA involvement. 


4. Security Considerations 


A protocol specified to meet these requirements, e.g., [ROHC], must 
be able to compress packets containing IPSEC headers according to the 
IPSEC requirement, 2.2.4. There may be other security aspects to 
consider in such protocols. This document by itself, however, does 
not add any security risks. 
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7. Full Copyright Statement 
Copyright (C) The Internet Society (2001). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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